过去几年中，现代软件开发的整体环境发生了巨大的变化。对我个人来说，这种变化与宇宙的加速膨胀差不多。第二个千年刚到来时，产业的发展看起来还不是那么快，只是逐步在前进。现在技术发展的复杂度和多样性已经可以用超音速来形容了，越来越快，出现了新的编程语言、开发工具、开发方法论等等。
由于类似 Uber、Facebook、Google 这样的企业需要构建全球解决方案的需求越来越多，使得技术变得更加全面也更加复杂。这种超级的复杂度，是能构建全球性巨大系统而必须付出的代价。但是对于构建相对简单的典型业务自动化系统，我们也应该付出相同的代价吗？
业务应用系统 - 自动化的沃土
2000年代初，在“能自动化就自动化”的格言激励下，业务自动化得到了极大的发展。这种自动化的结果就是所谓的业务应用系统（LOB Applications）。这是一个非常通用的术语，描述那些终极目的就是使得业务能更有效运行的非常重要的应用程序（大部分都是定制开发）。
通常，LOB 应用程序有下列特点：
- 特定领域 - 为特定领域的专业人员服务，而不是大众市场
- 以数据为中心 - 高度依赖关系型数据库，并且关系型数据库是应用程序的关键核心
- 面向事务（OLTP） - 代表系统的一致性和可用性级别（高一致性、高可用性），假设每个事务都符合 ACID
- 全面的业务逻辑 - 包含大量自定义的业务逻辑和数据处理算法
- 丰富的UI - 有成百上千的功能交互界面，使用相对标准的控件（文本框、复选框、按钮、表格等）
功能性的 LOB 系统还有一些通用的需求：
- 支持标准的身份验证机制，比如 SAML 和 LDAP
- 基于角色的访问控制
- 数据库行级别的安全性控制
- 数据更改日志（数据审计）
- 系统间的互操作性 - 能调用第三方 API 并且提供 API 用于集成
- 业务流管理引擎，支持工业标准的 BPMN
- 报表和 BI 能力
- 集成常用的服务，比如邮件（SMTP 和 IMAP）、文件存储（Amazon S3，WebDAV）、搜索引擎，等等
- 可扩展性，随着业务增长，解决方案可以升级
对于 LOB 应用程序的高需求形成了所谓的 “快速应用程序开发工具” 市场，最终演化成关注如何使得开发 LOB 应用程序更加有效和快速。
快速应用开发平台的演进
九十年代中期，对于业务自动化的需求开始呈指数型增长。因此，许多RAD平台应运而生，为开发 LOB 应用程序提供了快速通道。RAD 平台将易学的编程语言和高效的开发工具相结合，因此几乎任何人都可以在很短的时间创建基本的 LOB 应用程序。自动化的繁荣离不开 Microsoft Access、Oracle Forms、FoxPro，当然还有 Borland Delphi（当年的引领者们）。所以，在 2000 年代第一个十年结束的时候，基于 RAD 平台已经开发了大量的 LOB 系统。
后来 RAD 平台错过了当时正在到来的网络时代。Web 用户界面是个必不可少的需求，也同样需要可扩展性、可用性以及其他相关的需求。这些因素使得 Delphi 和其他的 RAD 工具不再流行，因为它们要么不能满足这些需求，要么演进太慢，没有跟上现实的发展速度。经过几年的停滞之后，成百上千的应用程序变成了难以再继续提供技术支持的遗产。甚至连 “RAD” 这个词本身都变成了贬义词，不再意味着“简单易用”和“快乐开发”，而是指过时和没有前途的东西。这种状态说明这个领域急需进行现代化改造。
迁移到主流的企业级技术栈似乎需要惊人的代价。同样的功能，对于 Delphi 开发者来说只需要一天，而对于 web 开发者则需要一周 - 疯了！很明显，新技术对于构建全部重新定义的应用程序来说是合适的，但是对于典型的 LOB 应用（比如有上面提到的那些功能）来说，会产生不少重复的开销。这种失衡显示了软件开发工具的市场中有一个未被发现的缺口，现在这个缺口已经被新一代的 RAD 平台占据。新一代已经从前辈们的骨灰中崛起，这就是说现代RAD市场的大多数代表不是传统产品的直接后代，而是从零开始将过去的最佳实践与主流技术相结合而开发的。
RAD 平台的基本原理
首先，我们着重介绍一下 RAD 平台的主要原理。换言之，我们看看与传统的开发技术栈相比，这些平台为什么会更加高效。
架构和高级别 API
现代 RAD 平台通过使用高级别抽象的全栈框架集成主流开发技术，从而解决这些技术之间的底层复杂性。这种高级别的框架为使用框架构建的所有应用定义了统一的坚实架构。了解这个架构非常重要，因为您应用程序中所有的边界和限制都源自于此架构。比如，您应用程序的扩展性怎样？是否模块化？可以用何种数据存储？能部署在什么样的环境？向后兼容性如何？还有很多其他的问题......
作为引入限制的回报，这种预定义的架构通过提供高级别的 API 加速 LOB 应用程序的开发，因为这些 API 都是贴近业务的。简单来说，框架将开发人员从底层技术中抽象出来，以便他们更专注解决业务问题。
这种使用高级抽象级别的方法在现代 RAD 框架中大量使用。其中有五个著名的玩家：Ruby on Rails、Grails、Django、CUBA Platform、Zend Framework。
通用基础功能
如上所述，RAD 平台主要用于 LOB 应用程序的开发。这种类型的应用程序有一些通用的需求，比如用户验证、数据访问限制、审计、文件存储、全文搜索、业务流程管理等等。RAD 平台满足这种需求是通过提供可重用的开箱即用功能或者扩展插件。
这种方案在现代 RAD 平台广泛使用。所以 CUBA 平台提供了扩展市场, Ruby on Rails 提供gems，Grails 使用插件， Django使用包。
开发工具
开发工具是最重要的部分，它不仅能保证高效的开发，还提供了更低的进入门槛、更平滑的学习曲线，当然，还有舒适的开发体验。事实证明这是可行的，因为这些工具仅集中在平台的预定义体系结构上：编程语言、使用的库和底层框架以及应用程序的结构（模块、附加组件、程序包）等等。
基于对采用的架构的广泛和深入的理解，RAD 工具可以为开发者提供终极便利。为了大致了解它们到底带来了什么便利，我们看看最常见的功能：
- 直观的可视化编辑器 - 用于新项目启动、项目配置、领域模型，UI 开发......
- 强大的代码生成 - 自动化最常用的脚手架代码和模板代码片段
- 智能提示 - 避免错误的使用元素，包含代码自动修复
- 高级导航 - 切换应用程序部分和配置部分
- 向导方式的版本升级过程 - 帮助迁移到平台的最新版本
- 分发准备 - 使方案易于部署
这里最生动的例子应该是 Embarcadero（前 Borland Delphi） 的 RAD Studio。另一个例子是 JHipster，RAD 家族的非典型成员 - 提供了命令行工具（CLI），主要关注项目的启动引导，为初始化 Java 项目配置提供非常多不同的选项。CUBA 平台提供了两种 RAD 工具：CUBA Studio 和 CUBA CLI，前一个是功能全面的强大 IDE，后一个是轻量级命令行工具。
低代码开发平台
如果您关注现代 RAD 市场及其发展，您一定听到或了解到大量关于所谓低代码开发平台（LCDP）的宣传语。各种口号表达出的低代码平台的理念是 ： 不远的未来将不再需要专业的开发人员。只需要雇佣业务主管，不需要再雇佣专业的软件开发人员。这就是我在之前的章节中都没有提到任何一个低代码平台的原因。但是，如果我们说到 RAD，不可能忽略 LCDP，因为这些平台造成了一个非常有趣的现象 - 使开发工具成为开发人员的竞争对手。
在售卖给业务主管之前，他们强调的主要商业价值是：便宜、更快、更高质量。没错，虽然需要您每年支付数十万美元的许可费用，但是由于不需要专业的开发人员（非常贵且头脑灵活），也不需要对本地设施进行维护，最终您会取得理想的收益 。他们通过演示使非技术人员感到惊讶，在演示中，销售经理仅通过单击鼠标即可创建出基本的业务应用程序……给人的印象是，业务人员（即非专业开发人员）就能够自动化（数字化）自己的业务需求。
从技术角度来看，LCDP 使用与 RAD 同样的原理：预定义的架构和高级别 API 、 即用型的典型功能和开发工具。这里最大的区别是此类平台的适用范围。为了使非专业人士能创建企业级软件，LCDP 供应商将开发过程缩减到只需要绘制流程图，但这种方式会牺牲很多其他的能力：熟悉的协作开发流程、源代码控制、可定制性、可扩展性、互操作性、兼容性、性能、自动测试…。结果是，LCDP 仅适合构建非常基本的业务系统。
现在，Mendix、Outsystems 和其他 LCDP 供应商尝试与专业开发者建立更友好的关系。但是似乎还有很长的路要走，因为目前大多数专业开发人员出于充分的理由并没有认真考虑低代码。
结论
有人会说“快速应用程序开发平台”听起来太老了，是过时的技术 - 我同意，现在这个词有很强的负面含义。为了使 RAD 技术重新具有新鲜感，Gartner(高德纳，全球最具权威的IT研究与顾问咨询公司) 提出了新的术语：企业低代码应用平台(LCAP)和企业高效应用平台(HPAP)。但是，深入研究后仍然可以看到其中使用了同样的原理：加速同一类应用程序的开发，当然，也具有相同的限制。看起来像是对 RAD 技术执行的“证人保护计划”，让其以新名称过着幸福的生活。
现代 RAD 框架、工具和平台的市场中产品众多，大多数都可快速开发 Web 应用程序。这些产品可分为两类：一种面向专业开发人员并遵循传统开发模式 ，另一种是面向非专业开发人员，在低代码技术方面的先行者。第一种主要通过提供更高级别的 API 和代码生成功能来提高软件开发速度，可以使开发人员避免编写样板代码和通用基础功能。第二种提供了强大的运行时环境和可视化工具，业务人员很喜欢这种方式，甚至不是因为开发速度快，而是因为这类产品提供了通过画图而不需要编码就能实现一些业务功能的能力。
关于如何选择 RAD 工具，没有人可以给出确定的建议或某些可量化的方法， 它在很大程度上取决于项目的功能和非功能性需求。但是，我想提醒您注意产品的定价和许可协议。对于某些产品，您必须要为之付出一笔巨款 - 价格每年可能从0到数十万美元不等。尤其是使用低代码平台时，您的账单往往会达到6位数字。 更糟糕的是，由于供应商锁定，您不太可能切换其他的供应商。